Reacti salajane koostisosa: süvitsiminek lepitusalgoritmi ja virtuaalse DOM-i võrdlemisse

`-i võidakse esitada nii:

{ type: 'div', props: { className: 'container', children: 'Hello World' } }

Kuna need on lihtsalt JavaScripti objektid, on nende loomine ja nendega manipuleerimine uskumatult kiire. See ei hõlma mingit suhtlust brauseri API-dega, seega ei toimu ümberarvutusi ega ümberjoonistamisi.

Kuidas virtuaalne DOM töötab?

VDOM võimaldab deklaratiivset lähenemist kasutajaliidese arendamisele. Selle asemel, et öelda brauserile kuidas DOM-i muuta (imperatiivne), deklareerite lihtsalt, milline peaks kasutajaliides antud oleku puhul välja nägema (deklaratiivne). React hoolitseb ülejäänu eest.

Protsess näeb välja selline:

1. Esmakordne renderdamine: Kui teie rakendus esmakordselt laaditakse, loob React teie kasutajaliidese jaoks täieliku virtuaalse DOM-puu ja kasutab seda esialgse päris DOM-i genereerimiseks.
2. Oleku uuendamine: Kui rakenduse olek muutub (nt kasutaja klõpsab nupul), loob React uue virtuaalse DOM-puu, mis peegeldab uut olekut.
3. Võrdlemine (Diffing): Reactil on nüüd mälus kaks virtuaalset DOM-puud: vana (enne oleku muutust) ja uus. Seejärel käivitab ta oma "diffing" algoritmi, et neid kahte puud võrrelda ja täpsed erinevused tuvastada.
4. Pakettimine ja uuendamine: React arvutab välja kõige tõhusama ja minimaalsema operatsioonide komplekti, mis on vajalik päris DOM-i uuendamiseks, et see vastaks uuele virtuaalsele DOM-ile. Need operatsioonid pakitakse kokku ja rakendatakse päris DOM-ile ühe optimeeritud järjestusena.

Uuenduste pakettimisega minimeerib React otsest suhtlust aeglase DOM-iga, parandades oluliselt jõudlust. Selle tõhususe tuum peitub "võrdlemise" etapis, mida ametlikult tuntakse lepitusalgoritmina.

Reacti süda: lepitusalgoritm

Lepitus on protsess, mille kaudu React uuendab DOM-i, et see vastaks uusimale komponendipuule. Algoritmi, mis seda võrdlust teostab, nimetame "võrdlusalgoritmiks" (diffing algorithm).

Teoreetiliselt on minimaalse arvu teisenduste leidmine ühe puu teiseks muutmiseks väga keeruline probleem, mille algoritmi keerukus on O(n³), kus n on sõlmede arv puus. See oleks reaalsete rakenduste jaoks liiga aeglane. Selle lahendamiseks tegi Reacti meeskond mõned geniaalsed tähelepanekud selle kohta, kuidas veebirakendused tavaliselt käituvad, ja rakendas heuristilise algoritmi, mis on palju kiirem – toimides O(n) ajaga.

Heuristika: võrdlemise kiireks ja ennustatavaks muutmine

Reacti võrdlusalgoritm põhineb kahel peamisel eeldusel ehk heuristikal:

Heuristika 1: erinevad elemenditüübid loovad erinevad puud

See on esimene ja kõige otsesem reegel. Kahe VDOM-sõlme võrdlemisel vaatab React kõigepealt nende tüüpi. Kui juurelementide tüüp on erinev, eeldab React, et arendaja ei soovi ühte teiseks teisendada. Selle asemel kasutab ta drastilisemat, kuid ennustatavat lähenemist:

• See lammutab kogu vana puu, eemaldades (unmounting) kõik vanad komponendid ja hävitades nende oleku.
• See ehitab uue elemendi tüübi põhjal nullist täiesti uue puu.

Näiteks vaatleme järgmist muudatust:

Enne: <div><Counter /></div>
Pärast: <span><Counter /></span>

Kuigi alamkomponent `Counter` on sama, näeb React, et juurelement on muutunud `div`-ist `span`-iks. See eemaldab täielikult vana `div`-i ja selle sees oleva `Counter`-i instantsi (kaotades selle oleku) ning seejärel paigaldab (mount) uue `span`-i ja täiesti uue `Counter`-i instantsi.

Põhiline järeldus: Vältige komponendi alampuu juurelemendi tüübi muutmist, kui soovite säilitada selle olekut või vältida selle alampuu täielikku uuesti renderdamist.

Heuristika 2: Arendajad saavad vihjata stabiilsetele elementidele `key` atribuudiga

See on vaieldamatult kõige olulisem heuristika, mida arendajad peavad mõistma ja õigesti rakendama. Kui React võrdleb alamelementide loendit, on selle vaikekäitumine itereerida läbi mõlema laste loendi samaaegselt ja genereerida mutatsioon kõikjal, kus esineb erinevus.

Indeksipõhise võrdlemise probleem

Kujutame ette, et meil on üksuste loend ja me lisame uue üksuse loendi algusesse ilma võtmeid kasutamata.

Esialgne loend:

• Üksus B
• Üksus C

Uuendatud loend (lisage 'Üksus A' algusesse):

• Üksus A
• Üksus B
• Üksus C

Ilma võtmeteta teostab React lihtsa, indeksipõhise võrdluse:

1. See võrdleb vana üksust indeksil 0 ('Üksus B') uue üksusega indeksil 0 ('Üksus A'). Need on erinevad, seega see muteerib esimest üksust.
2. See võrdleb vana üksust indeksil 1 ('Üksus C') uue üksusega indeksil 1 ('Üksus B'). Need on erinevad, seega see muteerib teist üksust.
3. See näeb, et indeksil 2 on uus üksus ('Üksus C') ja lisab selle.

See on väga ebatõhus. React on teinud kaks tarbetut mutatsiooni ja ühe lisamise, kuigi vaja oli vaid ühte lisamist algusesse. Kui need loendiüksused oleksid keerulised komponendid oma olekuga, võiks see põhjustada tõsiseid jõudlusprobleeme ja vigu, kuna olek võib komponentide vahel segi minna.

`key` atribuudi võimsus

`key` atribuut pakub lahenduse. See on spetsiaalne string-atribuut, mille peate elementide loendite loomisel lisama. Võtmed annavad Reactile iga elemendi jaoks stabiilse identiteedi.

Vaatame uuesti sama näidet, kuid seekord stabiilsete, unikaalsete võtmetega:

Esialgne loend:

• Üksus B
• Üksus C

Uuendatud loend:

• Üksus A
• Üksus B
• Üksus C

Nüüd on Reacti võrdlusprotsess palju nutikam:

1. React vaatab uue loendi alamelemente ja leiab elemendid võtmetega 'b' ja 'c'.
2. See teab, et elemendid võtmetega 'b' ja 'c' on juba vanas loendis olemas, seega see lihtsalt liigutab neid.
3. See näeb, et on uus element võtmega 'a', mida varem polnud, seega see loob ja lisab selle.

See on palju tõhusam. React tuvastab õigesti, et on vaja teha ainult üks lisamine. Komponendid, mis on seotud võtmetega 'b' ja 'c', säilitatakse, hoides alles nende sisemise oleku.

Võtmete kriitiline reegel: Võtmed peavad olema stabiilsed, ennustatavad ja unikaalsed oma õdede-vendade seas. Massiivi indeksi kasutamine võtmena (`items.map((item, index) =>

...

)`) on anti-muster, kui loendit saab kunagi ümber järjestada, filtreerida või kui sinna lisatakse/eemaldatakse üksusi keskelt, kuna see põhjustab samu probleeme kui võtme puudumine. Parimad võtmed on unikaalsed identifikaatorid teie andmetest, näiteks andmebaasi ID.

Evolutsioon: Stack-arhitektuurist Fiber-arhitektuurini

Eespool kirjeldatud lepitusalgoritm oli aastaid Reacti aluseks. Sellel oli aga üks suur piirang: see oli sünkroonne ja blokeeriv. Seda algset implementatsiooni nimetatakse nüüd Stack Reconciler'iks.

Vana viis: Stack Reconciler

Stack Reconciler'is, kui oleku uuendus käivitas uuesti renderdamise, läbis React rekursiivselt kogu komponendipuu, arvutas muudatused ja rakendas need DOM-ile – kõik ühe katkematu järjestusena. Väikeste uuenduste puhul oli see korras. Kuid suurte komponendipuude puhul võis see protsess võtta märkimisväärselt aega (nt üle 16 ms), blokeerides brauseri põhilõime. See muutis kasutajaliidese reageerimatuks, põhjustades kaadrite kadu, katkendlikke animatsioone ja halba kasutajakogemust.

Tutvustame React Fiberit (React 16+)

Selle probleemi lahendamiseks alustas Reacti meeskond mitmeaastast projekti, et lepitusalgoritmi tuum täielikult ümber kirjutada. Tulemus, mis avaldati React 16-s, kannab nime React Fiber.

Fiber-arhitektuur loodi algusest peale, et võimaldada samaaegsust (concurrency) – Reacti võimet töötada korraga mitme ülesandega ja vahetada nende vahel vastavalt prioriteedile.

"Fiber" on tavaline JavaScripti objekt, mis esindab tööühikut. See sisaldab teavet komponendi, selle sisendi (props) ja väljundi (children) kohta. Selle asemel, et kasutada rekursiivset läbimist, mida ei saanud katkestada, töötleb React nüüd fiber-sõlmede lingitud loendit, ükshaaval.

See uus arhitektuur avas mitu olulist võimekust:

• Inkrementaalne renderdamine: See suudab renderdamistöö jaotada väikesteks osadeks ja jaotada selle mitme kaadri peale.
• Prioritiseerimine: See suudab määrata erinevat tüüpi uuendustele erinevaid prioriteeditasemeid. Näiteks kasutaja sisestusväljale trükkimisel on kõrgem prioriteet kui taustal andmete hankimisel.
• Peatamine ja tühistamine: See suudab peatada töö madala prioriteediga uuenduse kallal, et tegeleda kõrge prioriteediga uuendusega, ning võib isegi tühistada või taaskasutada tööd, mida enam vaja pole.

Fiberi kaks faasi

Fiberi puhul on renderdamisprotsess jagatud kaheks eraldiseisvaks faasiks:

1. Renderdamise/lepituse faas (asünkroonne): Selles faasis töötleb React fiber-sõlmi, et ehitada "töös olev" (work-in-progress) puu. See kutsub välja komponentide `render` meetodid ja käivitab võrdlusalgoritmi, et teha kindlaks, milliseid muudatusi on vaja DOM-is teha. Oluline on, et see faas on katkestatav. React saab selle töö peatada, et tegeleda millegi olulisemaga, ja jätkata seda hiljem. Kuna seda saab katkestada, ei rakenda React selles faasis tegelikke DOM-i muudatusi, et vältida ebajärjekindlat kasutajaliidese olekut.
2. Kinnitusfaas (Commit Phase) (sünkroonne): Kui "töös olev" puu on valmis, siseneb React kinnitusfaasi. See võtab arvutatud muudatused ja rakendab need päris DOM-ile. See faas on sünkroonne ja seda ei saa katkestada. See tagab, et kasutaja näeb alati järjepidevat kasutajaliidest. Elutsükli meetodid nagu `componentDidMount` ja `componentDidUpdate`, samuti `useLayoutEffect` ja `useEffect` hook'id, käivitatakse selle faasi ajal.

Fiber-arhitektuur on aluseks paljudele Reacti kaasaegsetele funktsioonidele, sealhulgas `Suspense`, samaaegne renderdamine, `useTransition` ja `useDeferredValue`, mis kõik aitavad arendajatel luua reageerivamaid ja sujuvamaid kasutajaliideseid.

Praktilised optimeerimisstrateegiad arendajatele

Reacti lepitusprotsessi mõistmine annab teile võimekuse kirjutada jõudlusvõimelisemat koodi. Siin on mõned praktilised strateegiad:

1. Kasutage loendite jaoks alati stabiilseid ja unikaalseid võtmeid

Seda ei saa piisavalt rõhutada. See on loendite jaoks kõige olulisem optimeerimine. Kasutage oma andmetest unikaalset ID-d (nt `product.id`). Vältige massiiviindeksite kasutamist, välja arvatud juhul, kui loend on täiesti staatiline ega muutu kunagi.

2. Vältige tarbetuid uuesti renderdamisi

Komponent renderdatakse uuesti, kui selle olek muutub või selle vanem renderdatakse uuesti. Mõnikord renderdatakse komponent uuesti isegi siis, kui selle väljund oleks identne. Saate seda vältida, kasutades:

• `React.memo()`: Kõrgema järgu komponent (HOC) funktsionaalsete komponentide jaoks. See teostab komponendi atribuutide (props) pindmise võrdluse. Kui atribuudid pole muutunud, jätab React komponendi uuesti renderdamata ja taaskasutab viimati renderdatud tulemust.
• `useCallback()`: Komponendi sees defineeritud funktsioonid luuakse igal renderdamisel uuesti. Kui edastate need funktsioonid atribuutidena `React.memo`-sse mähitud alamkomponendile, renderdatakse alamkomponent uuesti, kuna funktsiooni atribuut on tehniliselt iga kord uus funktsioon. `useCallback` memoiseerib funktsiooni enda, tagades, et see luuakse uuesti ainult siis, kui selle sõltuvused muutuvad.
• `useMemo()`: Sarnane `useCallback`-ile, kuid väärtuste jaoks. See memoiseerib kuluka arvutuse tulemuse. Arvutus käivitatakse uuesti ainult siis, kui mõni selle sõltuvustest on muutunud. See on kasulik kulukate arvutuste vältimiseks igal renderdamisel ja stabiilsete objekti/massiivi viidete säilitamiseks, mida edastatakse atribuutidena.

3. Nutikas komponentide kompositsioon

See, kuidas te oma komponente struktureerite, võib jõudlust oluliselt mõjutada. Kui osa teie komponendi olekust uueneb sageli, proovige see eraldada osadest, mis ei uuene.

Näiteks selle asemel, et omada ühte suurt komponenti, kus sageli muutuv sisestusväli põhjustab kogu komponendi uuesti renderdamise, tõstke see olek omaette väiksemasse komponenti. Sel viisil renderdatakse uuesti ainult see väike komponent, kui kasutaja trükib.

4. Virtualiseerige pikki loendeid

Kui teil on vaja renderdada sadade või tuhandete üksustega loendeid, võib isegi õigete võtmete korral nende kõigi korraga renderdamine olla aeglane ja tarbida palju mälu. Lahenduseks on virtualiseerimine või akendamine (windowing). See tehnika hõlmab ainult väikese alamhulga üksuste renderdamist, mis on hetkel vaateaknas nähtavad. Kui kasutaja kerib, eemaldatakse vanad üksused ja paigaldatakse uued. Teegid nagu `react-window` ja `react-virtualized` pakuvad võimsaid ja lihtsalt kasutatavaid komponente selle mustri rakendamiseks.

Kokkuvõte

Reacti jõudlus ei ole juhus; see on tahtliku ja keeruka arhitektuuri tulemus, mis keskendub virtuaalsele DOM-ile ja tõhusale lepitusalgoritmile. Otsese DOM-iga manipuleerimise abstraheerimisega saab React uuendusi pakettida ja optimeerida viisil, mida oleks käsitsi hallata uskumatult keeruline.

Arendajatena oleme selle protsessi oluline osa. Mõistes võrdlusalgoritmi heuristikat – kasutades õigesti võtmeid, memoiseerides komponente ja väärtusi ning struktureerides oma rakendusi läbimõeldult – saame töötada koos Reacti lepitajaga, mitte selle vastu. Evolutsioon Fiber-arhitektuurini on veelgi nihutanud võimaluste piire, võimaldades uue põlvkonna sujuvaid ja reageerivaid kasutajaliideseid.

Järgmine kord, kui näete oma kasutajaliidest pärast oleku muutust hetkega uuenevat, võtke hetk, et hinnata virtuaalse DOM-i, võrdlusalgoritmi ja kinnitusfaasi elegantset tantsu, mis toimub kapoti all. See mõistmine on teie võti kiiremate, tõhusamate ja vastupidavamate Reacti rakenduste loomiseks ülemaailmsele publikule.